1. Field of the Invention
The present invention relates to the field of computer operating systems and the underlying code structure thereof.
2. Description of the Related Art
It is well known that a computer system relies on operating software, i.e. an operating system, to enable basic computer functionality. For example, an operating system allows a user to store and relieve files on a storage medium. Various approaches are used to provide the operating system software as part of the computer system. One approach utilized in IBM compatible computer systems is to provide a Basic Input Output System (BIOS) on a Read Only Memory (ROM) device. The BIOS contains the instructions for interaction between the various components of the computer system. The remainder of the Operating system functionality is loaded in Random Access Memory (RAM). In such implementations, the vast majority of the operating system functionality is loaded into the RAM. Other aspects of the operating environment namely the user interface tools, also would exist on RAM. This approach has the drawback of utilizing RAM which could otherwise be used for application programs.
An alternative approach is to provide as much operating system functionality into ROM as possible. This has the desired effect of freeing up RAM for application programs. This approach is used for the operating system for the Apple.RTM. Macintosh.RTM. family of computers, available from Apple Computer, Inc. of Cupertino, Calif. The organization of the Macintosh operating software between ROM and RAM as well as the Macintosh environment in general, is discussed in the publication entitled "Inside Macintosh Volume I", available from Addison-Wesley Publishing company.
The portion of the Macintosh operating environment that resides in ROM is comprised of two parts; the operating system and the user interface toolboxes. The operating system portion provides traditional operating system functionality. The toolboxes provides a standardized set of tools for application development. Examples of toolboxes include the Quickdraw Manager (for drawing figures on a display) Sound Manager and Resource Manager. The use of such toolboxes would be well known to one having familiarity with developing applications for the Apple Macintosh family of computers.
In the Macintosh environment routines based in ROM are typically accessed using what is known as the A-Trap dispatching mechanism. The A-Trap dispatching mechanism is described in the publication "Programmer's Guide To MPW Volume 1", Mark Andrews, available from Addison-Wesley publications (MPW is an acronym for Macintosh Programmer's Workshop). The A-Trap dispatching mechanism allows for the calling of the ROM based routines symbolically through the trap dispatcher, rather than by absolute ROM address.
One problem with storing code in ROM is that it is static and cannot be fixed (absent physically replacing and re-writing the ROM). Accordingly, adding functionality or fixing "bugs" found in the operating system ROM code is very tricky. To fix a bug or add functionality, one must either patch the vectors maintained by the A-Trap dispatching mechanism, or patch the private vectors maintained by some of the tool box managers. "Patch" is a term of art which refers to new code introduced to fix prior code or to add functionality. A ROM vector causes a jump to a location in RAM where the patch code may reside. However, because there are a limited number of such vectors, most of the code is called directly and cannot be easily patched.
To patch non-vectorized code, one must be very creative. In some cases, all clients of the offending code can be patched. Clients in this context refers to code that calls or receives data from the offending code. In other cases a routine called by the offending routine may be patched to fix what the calling routine did wrong. This is called a "come from" patch and it usually identifies the caller by comparing the return address with a known absolute address. When small patches are made to large routines, it is common practice to call the existing code in ROM to save memory. Usually this is done by jumping to the absolute address in the ROM. In doing so, the absolute address in ROM becomes hard coded into the patch.
Because of these absolute addresses hard-coded into the patches, the ROM is very difficult to maintain. Much care must be taken to assure any changes or additions to the ROM will not change the addresses of the existing code. This has the undesirable effect of making the ROM based code non-relocatable (because of code reliance on absolute addresses). This becomes even more difficult as more operating system code is written in high level languages.
Despite such obstacles, it is desirable to place operating system functionality in ROM because it reduces the amount needed for RAM. Consequently, this flees RAM resources to be used for application software programs. Another advantage is that it is easier to protect ROM based code from unauthorized copying.
Moreover, as application software becomes integrated into base functionality of computer system, it is likely the application software itself will become ROM based. As more functionality is placed in ROM, the foregoing maintenance difficulties are compounded.
Thus, it is an object of the present invention to provide a mechanism for generating code that will in reside in ROM so that patches or additional function may be added with greater ease. It is a further object of the present invention to simplify the patch installation process.